package mysql8学习.高级.第14章_MySQL事务日志;

/**
 * 将完成的事务进行记录，即使宕机了也不会影响写入磁盘的redo日志 记录，
 * 恢复后，由于redo日志在磁盘中，不受影响，所以修改的信息并没有丢失
 * 会保存在一个 redo.file  文件中
 *
 * 一方面， 缓冲池可以帮助我们消除 CPU和磁盘之间的鸿沟，
 * checkpoint机制可以保证数据的最终落盘,然而由于
 * checkpoint并不是每次变更的时候就触发的，而是master线程隔一段时间去处理的。
 * 所以最坏的情况就是事务提交后，刚写完缓冲池，数据库宕机了,那么这段数据就是丢失的,无法恢复。
 * 另一方面，事务包含持久性的特性,就是说对于一个已经提交的事务，
 * 在事务提交后即使系统发生了崩溃，这个事务对数据库中所做的更改也不能丢失。
 *
 * 那么如何保证这个持久性呢? 一个 简单的做法:
 * 在事务提交完成之前把该事务所修改的所有页面都刷新到磁盘,
 * 但是这个简单粗暴的做法有些问题:
 * ● 修改量与刷新磁盘工作量严重不成比例
 *   有时候我们仅仅修改了某个页面中的一个字节，
 *   但是我们知道在InnoDB中是以页为单位来进行磁盘I/O的，
 *   也就是说我们在该事务提交时不得不将一个完整的页面从内存中刷新到磁盘,
 *   我们又知道一个页面默认是16KB ;
 *   大小，只修改一个字节就要刷新16KB的数据到磁盘上显然是太小题大做了。
 * ● 随机I/O刷新较慢
 *   一个事务可能包含很多语句，即使是一条语句也可能修改许多页面，
 *   假如该事务修改的这些页面可能并不相邻，
 *   这就意味着在将某个事务修改的Buffer Pool中的页面刷新到磁盘时，需要进行很多的随机I0 ,
 *   随机I/O比顺序I/O要慢，尤其对于传统的机械硬盘来说。
 *
 * 另一个解决的思路:
 * 我们只是想让已经提交了的事务对数据库中数据所做的修改永久生效,
 * 即使后来系统崩溃，在重启后也能把这种修改恢复出来。
 * 所以我们其实没有必要在每次事务提交时就把该事务在内存中修改过的全部页面刷新到磁盘，
 * 只需要把修改了哪些东西记录一下就好。
 * 比如，某个事务将系统表空间中第10号页面中偏移量为100处的那个字节的值1改成2。
 * 我们只需要记录一下:将第0号表空间的10号页面的偏移量为100处的值更新为2。
 *
 * InnoDB引擎的事务采用了WAL技术( Write-Ahead Logging),
 * 这种技术的思想就是先写日志，再写磁盘,只有日志写入成功，才算事务提交成功,
 * 这里的日志就是redo log。
 * 当发生宕机且数据未刷到磁盘的时候，可以通 过redo log来恢复,
 * 保证ACID中的D ,这就是redo log的作用。
 *
 *
 */
public class B1_为什么需要redo日志 {
}
